セールスvs開発：100%の「ビッグバン」か、60%の「小出し」か。終わらない聖戦
IT業界やプロダクト開発の現場にいると、必ずと言っていいほど目撃する光景があります。それは、新機能や新サービスのリリース方針を巡る、セールスと開発（エンジニア）の冷戦です。
「中途半端なものを客に出せるか！ 100%完成させてから『一気に』華々しくリリースさせろ！」と叫ぶセールス。
「いやいや、いきなり全部出すなんて自殺行為ですよ。60〜70%でいいから細かく出して修正させてくれ」と嘆く開発。
これ、どっちかが怠慢なわけでも、わがままなわけでもないんですよね。お互いに見ている「リスク」の種類が違うだけなんです。今回は、この埋まらない溝について、それぞれの言い分を書き出してみます。
セールスの心情：「矢面に立つのは俺たちだ」
まず、セールス側の気持ちになってみましょう。彼らは日々、顧客と最前線で対峙しています。顧客からの信頼こそが彼らの商売道具です。
そんな彼らにとって、開発が言う「とりあえず60%でリリースして、様子を見ながらアップデートします（アジャイル的な発想）」というのは、ぶっちゃけ恐怖でしかありません。
「え、この機能まだないの？ お客さんに『なんでないんですか』って聞かれたらなんて答えればいいの？」 「機能として足りてない部分があるのに、どうやって『素晴らしい製品です』ってプレゼンしろと？」
というのが本音でしょう。バグ云々以前に、**「顧客を納得させるための材料（機能）が足りていない」**という事実に絶望するわけです。「ロードマップ上にはあります」なんて言葉で納得してくれるほど、現場は甘くないと彼らは知っています。
そして、ここにはもっとドロドロした感情もあります。 もし不具合が起きたり、機能不足でクレームになったりしたとき、客先で怒鳴られ、頭を下げるのは誰か？ セールスなんですよ。開発チームにとっては「解決可能な技術的課題」という認識かもしれませんが、現場のセールスにとっては「胃がキリキリする謝罪の時間」が増えるわけです。
自分たちばかりが損な役回りを押し付けられているような、そんなある種の被害者意識にも似た感情が根底にあります。だからこそ、彼らは自分たちを守るための「完璧な盾」、つまりビッグバンリリースを望みます。すべての機能が完璧に動作し、ドキュメントも揃い、「これなら文句言われないだろ！」という状態で戦場に出たいのです。
彼らにとってのリスクとは、「期待外れのものを出して信頼を失うこと」であり、同時に「自分たちが理不尽に傷つくこと」でもあるのです。
開発の心情：「一度に出すのはハイリスクすぎる」
一方で、開発チームの言い分はまるで逆です。
彼らにとっての「ビッグバンリリース」は、もはや無謀なギャンブルにしか見えません。 「要件定義から開発、テストまで半年かけて、一度もユーザーに見せずにリリースする？ 正気か？」というのが彼らの感覚です。
これは決して怠慢ではありません。技術的なリスクヘッジと、価値提供の確実性を考えてのことなんです。 もし半年分の機能を一気にリリースして、そこで重大なバグが見つかったらどうなるか。影響範囲が広すぎて原因の特定が困難になりますし、修正にも膨大な時間がかかります。小出しにしていれば、何かあっても「直近の変更箇所」だけを見ればいい。つまり、不具合を最小限に抑え、安全に運用するための定石なんです。
さらに、彼らは「本当に使われるものを作りたい」と強く思っています。 「完璧だと思って100%作り込んだ機能が、実はお客さんにとってはどうでもいい機能だった」なんてことはザラにあります。ビッグバンリリースだと、そのズレに気づくのが遅すぎて修正が効きません。
だからこそ、彼らは60〜70%でのリリースを望みます。 まずはコアとなる機能だけで出して、実際に使ってもらい、「ここが使いにくい」「もっとこうしてほしい」という反応を見ながら育てていく。それが結果として、顧客に最短で最大の価値を届けるための「最適なプロセス」だと信じているからです。
彼らにとってのリスクとは、「安全確認のできていない巨大な塊をリリースすること」であり、「顧客が本当に求めているかどうかわからないものに時間を費やすこと」なんですね。
「理論」で殴る開発、「感情」で守るセールス
結局のところ、この争いの原因は「職務としての価値観」が根本的に違うことにあります。
開発者は、どうしても「正しさ」や「理論」でセールスに向き合ってしまいがちです。 「小さく出したほうが、結果的にお客さんの要望に早く応えられます」「不具合が出てもすぐに直せるので、品質も安定しますよ」と。
言ってることは100%正しいんです。 でも、これではセールスとは一生わかり合えません。なぜなら、セールスが抱えているのは「理論的な疑問」ではなく、「現場で立ち往生するかもしれない」という不安だからです。
この不安には、明確なデータも根拠もありません。「実際にクレームが来るか？」と問われれば「わからない」のが正直なところでしょう。でも、わからないからこそ不安なのです。 「理論的には正しいかもしれないけど、もし明日お客さんに詰められたら、俺はどうすればいいんだ？」 という漠然とした不安に対して、「開発プロセスとしてはこちらが効率的です」と返されても、会話は噛み合いません。理論一辺倒で説得しようとすればするほど、セールスは「現場の苦労も知らないくせに」と心を閉ざしてしまいます。
まずは「不安」を聞くことから
では、開発者はどうすればいいのか。それは、いきなり「開発の正論」をぶつけるのではなく、まずはセールスの不安に寄り添うことかもしれません。
「理論で論破する」のではなく、「対話」が必要です。 「この状態でリリースしたら、具体的にどんな場面で困りそうですか？」 「お客さんに何て突っ込まれるのが一番心配ですか？」
そうやって相手の「不安の正体」を引き出し、それを解決するための材料を一緒に考える姿勢を見せることです。 たとえば、「機能が足りない部分は、こう説明すればメリットとして伝わりませんか？」とか、「こういうツッコミが来たら、こう返せば納得してもらえる言い方がありますよ」といった具合に。
セールスが求めているのは「完璧なソフトウェア」そのものというより、「これなら自信を持って売れる、もし何かあっても組織として対応できる」という確信なんですよね。
その確信を持ってもらえて初めて、開発側の「正義」も届くようになります。「だからこそ、今回はあえて小出しにして、早く改善できるようにしたいんです」という理屈が、相手の腹に落ちるようになるわけです。
違う生き物として、同じ船に乗る
セールスは「売るための安心」を求め、開発は「作るための最適解」を求める。 この両者の視点が完全に一致することは、たぶん未来永劫ありません。職務が違う以上、見ている景色も守るべき正義も違うからです。
無理に同じ方向を向こうとしなくてもいいのかもしれません。 ただ、開発者がふと手を止めて「セールスは今、何に怯えているんだろう？」と想像してみる。セールスも「開発は何を実現しようとしているんだろう？」と考えてみる。
そうやってお互いの背負っている不安やリスクを少しだけ理解し合うことができれば、不毛な冷戦も多少は建設的な対話に変わっていくのかもしれません。
